…a NOT NULL

Round-5 audit on develop @ 2155e25 (post-PR-#537 merge) flagged three
follow-ups. All three applied here.

## SIG-P2-NOVO — `readVarint` off-by-one in the shift guard
`src/Signal/libsignal.ts`

The guard was `if (shift > 35)`, but JavaScript `<<` is modulo-32 on the
right operand. The 5 valid byte shifts are 0, 7, 14, 21, 28; after the
5th byte the increment makes `shift = 35`. With `>`, byte 6 was still
read on the next iteration and `(byte & 0x7f) << 35` silently folded
into `<< 3`, producing a corrupt value that the outer `>>> 0` happily
accepted as a "valid" uint32. The effect was subtle: a crafted
PreKeyWhisperMessage with a 6-byte varint field tag could neutralise
`extractIdentityFromPkmsg`'s field-3 (identityKey) parse — degrading
the audit-SIG-A1 identity-change detection signal to undefined for that
pkmsg. Decryption itself stays correct (libsignal processes the
ciphertext independently); only the WARN-on-identity-change loop loses
visibility.

Fix: `shift >= 35` (one character). Comment rewritten to document the
JS shift-mod-32 reasoning so future readers don't undo it.

## MDB-schema-raw_string — `jid.raw_string` NOT NULL
`src/Utils/multi-db-sqlite/schemas/msgstore.ts`

`raw_string TEXT` (nullable) had two distinct failure paths:
  (1) SQLite treats NULL as DISTINCT inside a UNIQUE index, so a
      malformed insert path producing NULL would silently bypass the
      `jid_raw_string_idx` uniqueness guarantee.
  (2) `selectJidIdByRaw` filters by `WHERE raw_string = ?`, and SQL
      `NULL = NULL` is FALSE — a row with raw_string NULL would never
      be findable again, making `rowIdFor` throw "failed to materialize
      jid row" for every subsequent access.

`CREATE TABLE IF NOT EXISTS` is a no-op when the table exists, so
legacy databases keep the nullable column (no migration risk); new
databases get the constraint enforced.

## MDB-P2-A — `jid_map.sort_id` NOT NULL DEFAULT 0
`src/Utils/multi-db-sqlite/schemas/msgstore.ts`

`sort_id INTEGER` (nullable) was first flagged in round-3. A row
inserted without an explicit `sort_id` would end up as NULL.
`ORDER BY sort_id DESC` ranks NULLs LAST in SQLite, which would
silently demote a freshly-inserted-but-NULL row below older ones —
the opposite of the `getAllLidsForPn` "last write wins" intent.
`upsertMap` always provides a real epoch-ms tick today, so the
default is purely defensive against future code paths that bypass
upsertMap.

## Not applied (intentional)

- **SOCK-P1** (`ev.flush()` incondicional) — toca buffer behavior that
  feeds the carousel/list/button render path. Per project constraint
  (no regressions in carousel/list/button), needs E2E coverage before
  any change.
- **UTL-P1-A/B** (subarray aliasing + double-count fileLength) —
  needs benchmark/integration test before mutating HMAC stream and
  upload pipeline.
- **MDB-P1-C** (`clear()` retry) — needs crash-recovery test.
- **MSG-P1-A/B/C/D** — still deferred pending E2E, same as PR #537.

## Validation

- `tsc --noEmit -p tsconfig.json` exit 0
- `eslint` on the 2 touched files: 0 errors
- Local jest failures are pre-existing `better-sqlite3` native binding
  misses on Windows toolchain — unrelated. CI Linux is the gate.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>